rfc(feature): Capture SDK options - #162

Describe that we do not capture SDK config today, and the adjacent
signals (event SDK metadata, client reports). Remove the empty
Supporting Data section for now.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Option A (preferred): a dedicated, first-class envelope item for SDK
options. Option B: expand error events to carry the config.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Propose a language-agnostic, primitives-only payload: sdk (identity +
opt-in integration status via `active`), meta, options, integration_options,
and a free-form `_other` bucket. Cover callback normalization, generic
integration options, reflecting which integrations are actually used, and
cross-SDK naming.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

- Sending: server SDKs (debounced send after init, configurable delay,
  flush on shutdown), client SDKs (send-on-every-init vs. sampling),
  and a note that serverless shares client constraints.
- Storing: store-every-record vs. dedup-by-release (recommended), with
  an open question on whether release is a sufficient dedup key.
- Add top-level `timestamp` to the envelope; note options are scrubbed
  server-side (no client-side scrubbing).
- Add Drawbacks.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Rename XXXX -> 0162 now that the PR is open, fill in the RFC PR link,
and add the index entry to README.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Add an "Envelope item type" subsection recommending `sdk_config`, with
`sdk_options` and `client_config` as considered alternatives.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

- Add "Not in scope / Follow-up work" (product usage; removing SDK
  metadata from events, which needs a backfill from sdk_config).
- Cross-SDK naming: recommend leaving option names unspecced (native
  SDK names as-is) rather than a canonical catalog.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…n Relay

Rework the envelope shape so SDKs send their final/effective `options` as-is
plus a flat `options_set_by_user` provenance array, and Relay derives
`normalized_options` (a canonical-keyed subset) at ingestion. Add explicit
serialization rules (functions -> [Function], integrations -> name), the
normalization catalog, and rationale for both decisions (Relay-side
normalization; effective options + flat set-by-user array).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…iming; add Open Questions

- Rename the per-integration runtime signal `active` -> `applied` (clearer:
  "took effect at runtime" rather than enabled/disabled).
- Reframe server-SDK send timing: debounce is one example default; any
  settling hook/mechanism is fine as long as final options are captured.
- Note the new `sdk_config` envelope item degrades gracefully — older
  Relay/self-hosted discards the unknown item and processes the rest.
- Add an Open Questions section (new-envelope-type infra: rate limits,
  payload/size limits, data category/quota/billing, outcomes) and reference
  the release dedup-key question.
- Clarify scrubbing: primarily server-side; SDKs MAY scrub known-sensitive
  values as best-effort, without guaranteeing fully-scrubbed data.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Replace the two parallel name-keyed maps (`sdk.integrations` for status,
top-level `integration_options` for options) with a single top-level
`integrations` map. Each entry holds the integration's runtime `applied`
status plus its configured options nested under an `options` key, so
arbitrary user options can never collide with well-known status keys.

Also document a known limitation of sending effective options: the
user-provided *form* is lost when the SDK coerces a value (notably
`integrations` passed as a function -> resolved array). Note this is rare
(essentially `integrations` and `stackParser` in JS) and can be layered on
later via a sparse `options_user_provided` block without reworking the shape.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…ns hash

Replace the two-strategy + hybrid dedup framing with a single rule:
deduplicate by `release` + `environment` + `dist` plus an optional,
SDK-provided options hash that is stable across instances sharing a config.
When present, the server folds the hash into the dedup key (capturing
within-release variation); when absent, dedup falls back to the composite key.

The hash is SDK-side by design (a robust server-side canonical hash isn't
feasible) and, if used, MUST be stamped on every event — as an attribute on
spans/logs and a context field on error/transaction events — so events
correlate exactly to their config. Correlation now falls out of the key:
bucket-level without a hash, exact with one. Update Open Questions and the
Drawbacks bullets to match.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>